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Information  Resources  Management  Team  Charge  and  Information 
Resources  Management  Team  Members 
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Information  Resources  Management  Team  Charge 


Composition 

The  Information  Resource  Technology  Team  (IRMT)  will  be  comprised  of  the  Assistant 
Secretary  for  Administration,  two  members  from  the  Administrative  Divisions,  two  members 
from  the  Health  divisions,  two  members  from  the  Environmental  Protection  Divisions,  two 
members  from  the  Natural  Resource  divisions,  and  two  members  from  the  Regional  Offices.  The 
Deputy  Secretary  and  the  General  Counsel  will  serve  as  ex  officio  members.  A representative 
from  the  Office  of  State  Controller/  Information  Resource  Management  staff  will  serve  as  an  ex 
officio  member.  The  Team  will  be  staffed  by  the  Director  of  the  Division  of  Computer  Systems. 

Responsibility 

The  IRMT  will  serve  in  an  advisory  capacity  to  senior  management  and  to  the  Director  of  the 
Division  of  computer  Systems.  Working  within  the  framework  of  total  quality  management,  the 
IRMT  will  seek  to  do  the  following: 

• Develop  and  provide  oversight  for  all  departmental  information  technology  related 
policies  and  procedures,  to  include  setting  standards  for  hardware  and  software. 

• Provide  DEHNR  senior  management  with  periodic  reports  on  the  status  on  information 
technology  in  the  Department. 

• Recommend  to  DEHNR  senior  management  changes  in  the  strategic  direction  of  the 
Division  of  computer  systems,  including  organizational  structure,  technology,  and 
staffing  patterns  to  best  serve  the  needs  of  the  Department. 

• Assist  the  Director  of  the  Division  of  Computer  Systems  in  gathering  feedback  from 
users  that  will  improve  efficiency  and  effectiveness  of  information  technology  and 
enhance  customer  satisfaction. 

• Develop  a communication’s  strategy  for  conveying  the  actions  and  recommendations  of 
the  IRMT  to  the  Department. 

• Review  the  implications  of  global  positioning  and  GIS  for  the  Department  and  make 
recommendations  to  senior  staff. 
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White  Paper  on  the  Organization  of  Computing  Resources  in  DEHNR 


White  Paper  on  the  Organization  of  Computing  Resources  in  DCHNR 
Introduction 

DEHNR  is  a complex  organization  with  divisions  that  have  specialized,  highly  technical 
roles.  Many  of  these  divisions  have  considerable  contact  with  the  public.  They  are  also 
responsible  for  the  execution  of  legislation  and  executive  orders  that  are  highly  visible  and 
potentially  controversial  or  volatile.  A key,  strategic  factor  in  enhancing  staff  productivity 
and  in  the  successful  execution  of  divisional  responsibilities  is  the  processing  of  and  access 
to  timely,  reliable  information.  In  turn,  such  access  can  only  occur  when  information 
technology  (IT)  resources  are  well  coordinated  and  adequately  funded. 

DEHNR  IT  resources,  originally  housed  in  some  of  the  larger  divisions,  have  been  largely 
centralized  and  are  now  located  in  a single  administrative  division,  the  Division  of 
Computer  Systems  (DCS).  Centralization  of  the  IT  function  occurred  for  a number  of 
reasons.  First,  the  department  needed  a central  contact  point  for  other  state  agencies  like 
SIPS.  A single  unit  could  potentially  provide  better  service  to  DEHNR  as  a whole  which 
has  a number  of  smaller  divisions  without  computing  resources.  The  centralized 
organization  would  enable  central  systems  support  for  networking  and  telephony,  and 
foster  comparable,  high  level  training  for  the  entire  IT  staff.  This  centralized  staff  would 
also  be  of  sufficient  size  to  provide  career  advancement  opportunities.  Clearly  a number  of 
compelling  reasons  fostered  the  reorganization. 

Unfortunately,  underlying  this  reorganization  is  the  assumption  that  resources  originally 
assigned  to  the  different  divisions  would,  when  brought  together,  be  sufficient  to  cover  the 
needs  of  the  entire  department.  This  was  not  the  case  in  1989  and  with  the  loss  of  a 
position  since  then,  is  not  the  case  now.  The  hoped  for  outcomes  have  only  been  partially 
realized,  and  as  a result,  considerable  dissatisfaction  currently  exists  among  both  IT  staff 
and  many  of  the  program  personnel. 

Program  personnel  are  facing  significant  increases  in  their  information  workload  with  new 
legislation  and  increasing  public  expectations.  These  pressures  dictate  that  existing 
systems  are  well-supported,  and  that  new  state-of-the-art  systems  be  brought  on  line  in  a 
timely  fashion.  DCS  personnel  recognize  these  pressures  and  have  been  working  very  hard 
to  respond,  but  they  are  badly  understaffed  and  lack  many  of  the  support  resources  (e.g. 
training  and  being  fully  networked)  that  they  need  to  respond  effectively.  Thus  both 
parties  are  frustrated  and,  although  all  parties  are  making  conscientious  efforts,  concern  is 
widespread  that  a major,  visible  application  or  more  general  system  breakdown  could  occur 
as  a result. 
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The  following  white  paper  is  a first  step  in  a larger  effort  to  address  these  problems.  The 
objective  of  this  paper  is  to  review  the  current  role  of  DCS  in  the  current  resource 
constrained  environment  and  develop  a set  of  recommendations  that  may  address  some  of 
the  current  problems  and  set  the  stage  for  further  resolution  in  the  future. 

To  develop  this  white  paper,  all  DCS  personnel,  many  program  representatives,  several 
senior  DEHNR  administrators,  and  senior  representatives  from  SIPS  and  the  IRMC  were 
interviewed.  A preliminary  set  of  questions  was  developed  to  provide  a base  of 
information  for  comparative  purposes.  Additional  questions  were  developed  based  on 
initial  discussions,  and  opportunities  for  open-ended  discussions  were  also  provided.  In 
addition,  a number  of  documents  were  reviewed  including:  the  KPMG,  Performance 
Audit  of  Information  Technology  and  Telecommunications,  the  SIPS  Business  Plan,  the 
DCS  IRMC  plan,  and  memoranda  from  DCS  regarding  current  systems  support 
responsibilities.  Finally,  organization  charts  and  IT  staffing  reports  were  provided  by 
various  DEHNR  administrative  units. 

Overview 

The  Computing  Environment  and  Existing  DCS  Resources 

The  DEHNR  computing  environment  is  large,  complex,  and  relatively  antiquated.  DEHNR 
has  roughly  one  hundred  legacy  applications  which  currently  reside  on  the  SIPS  ES9000 
mainframe.  Of  these,  about  seventy  are  associated  with  environmental  programs;  twenty- 
five  support  health  programs,  and  the  remainder  provide  support  for  natural  resources  and 
administrative  functions.  Examples  of  important  systems  supported  by  DCS  programmers 
are  the:  Birth  Certification  System,  Vital  Statistics  System,  Immunization  School  Survey 
System,  Tuberculosis  Control  Assessment  System,  Contract  Data  System,  Claims  Budget 
System,  Restaurant  System,  and  the  Disaster  Recovery  Files  Systems.  Most  of  the  legacy 
systems  are  at  least  ten  years  old,  are  not  well  documented,  and  are  time-consuming  to 
maintain. 

DEHNR  houses  several  mini  computers  including  two  IBM  Systems  36s,  two  WANGs,  a 
DEC  VAX  and  a Data  General  mini  computer.  These  are  all  old  platforms  and  as  such 
require  greater  maintenance  and  are  generally  suspect  in  terms  of  their  reliability.  DEHNR 
divisions  own  about  two  thousand  PCs.  Of  these,  roughly  seven  hundred  are  LAN 
networked,  and  twenty-one  of  the  LANs  are  connected  via  the  state's  WAN.  Others  are 
connected  directly  to  the  SIPS  mainframe  via  3270  emulation.  In  addition,  DEHNR  and  the 
county  health  departments  have  over  2500  SNA  nodes  connected  to  the  SIPS  mainframe. 

In  summary  this  computer  environment  is  highly  heterogeneous  with  old  platforms  and 
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applications.  It  is  characterized  by  complex  networking  requirements  both  in  kind  and 
number  of  connections,  and  finally  it  is  an  environment  that  crosses  many  organizational 
and  physical  boundaries.  Such  an  environment  requires  considerable  support  resources. 
The  heterogeneous  platforms  and  applications  greatly  expand  the  set  of  skills  necessary  to 
maintain  them.  The  age  of  the  platforms  and  the  outdated  programming  languages  require 
programmers  to  spend  the  bulk  of  their  time  on  maintenance,  and  the  large  and  rapidly 
growing  number  of  connections  exacerbate  network  complexity  and  problem  solving. 

The  principle  responsibility  for  support  of  this  DEHNR  computing  environment  rests  with 
DCS.  (SIPS  is  contracted  to  provide  application  support,  and  larger  divisions  have  some 
permanent  IT  resources.  A number  of  contract  programmers  have  also  been  hired  primarily 
by  other  divisions  to  provide  additional  development  and  maintenance  support.) 
Unfortunately  the  resources  committed  to  DCS  are  relatively  small.  DCS  expenditures  for 
FY93/94  were  about  $1 .5m.  Of  this  total,  $1 .3m  was  spent  on  salaries,  $.  1 Om  on 
processing,  and  $.10m  on  equipment  purchase  and  maintenance.  Currently  DCS  has 
twenty-three  positions.  Three  are  primarily  administrative  positions.  Fifteen  are 
analyst/programmers,  and  the  remainder  are  computing  systems  and  telephony  support 
staff.  The  DCS  programmers  are  trained  primarily  in  COBOL/2  and  work  with  IMS  or 
VSAM  databases/files.  A few  of  the  programmer/analysts  have  trained  themselves  in  fourth 
generation  languages  like  FOCUS  and  in  the  use  of  CASE  tools  for  application 
development.  The  system  support  personnel  provide  networking  support  primarily  for 
Ethernet  networks  with  Novell  network  operating  systems.  They  also  support  WAN  access 
with  the  installation  and  maintenance  of  various  routers  and  bridges.  Finally,  the  systems 
support  staff  assist  in  installation  and  support  of  commonly  used  applications  like  e-mail, 
spreadsheets,  and  wordprocessors.  Clearly  the  resources  available  to  DCS  are  constrained. 
Even  from  this  cursory  overview,  it  is  clear  that  current  DCS  staffing  levels  are  taxed  to  the 
limit  to  simply  maintain  the  existing  systems. 

At  the  same  time,  DEHNR  computing  users'  needs  and  expectations  are  increasing 
dramatically  as  their  "customers"  expect  more  and  as  computing  technology  changes  at  an 
almost  breathtaking  pace  . The  latest  IRM  plan  for  DEHNR  includes  worthwhile  requests 
that  could  easily  double  the  current  development  and  maintenance  workload  of  DCS  As 
examples,  the  Division  of  Land  Resources  would  like  to  digitize  it  topographical  data  and 
access  the  GIS  corporate  database.  The  Zoo  proposes  the  creation  of  a park-wide 
information  technology  network.  The  Division  of  Solid  Waste  Management  wants  to 
upgrade  its  voice  and  electronic  communications  systems.  The  Division  of  Environmental 
Health  seeks  to  provide  on-line  access  to  sample/analysis  and  compliance  data. 
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All  of  these  requests  and  many  others,  stem  from  ever  increasing  demands  of  the  public 
and  legislature  and  from  a better  informed  group  of  DEHNR  users  who  see  the  changes  in 
technology  - a distributed  environment,  object-oriented  databases,  workflow  and 
workgroup  software,  inexpensive  imaging  - and  know  whafs  possible. 

IT  Issues : 

A number  of  significant  issues  have  emerged  as  a result  of  this  basic,  pronounced 
imbalance  between  program  needs/expectations  and  DCS  resources.  Most  importantly, 
users  have  reported  service  bottlenecks  across  the  board  - in  application  development, 
equipment  and  software  purchasing,  LAN  and  WAN  support,  password  administration,  and 
the  processing  of  administrative  paperwork.  These  bottlenecks  and  the  pressures 
experienced  by  program  areas,  have  led  a number  of  divisions  to  either  establish  or  plan  to 
establish  IT  functions  within  their  areas.  Several  divisions  have  also  hired  contractors  to 
develop  and  maintain  applications.  In  turn,  such  suboptimization  has  exacerbated  problems 
of  coordination  and  ironically,  has  increased  the  demands  for  support  from  DCS.  In 
addition,  DCS  has  become  largely  reactive  with  little  time  to  anticipate  changes  in  user 
requirements  or  to  prepare  for  changing  technologies.  In  conjunction  with  rapid  turnover 
in  DCS  leadership,  this  reactive  posture  has  inhibited  DCS  from  clearly  defining  its  role 
as  a unit  or  the  roles  of  its  individual  staff  members. 

Program  staff  indicate  that  well-intentioned  promises  regarding  application  development 
have  been  made  but  haven't  been  kept,  leaving  staff  members  skeptical  and  very  frustrated. 
The  delays  are  substantial  for  a significant  number  of  programs  and  sections.  In  some 
cases,  programs  have  been  waiting  years  for  hoped-for  applications.  A section 
representative  noted  that  he  has  had  the  money  to  develop  an  externally  mandated 
application  since  1 990.  He  made  his  request  through  formal  channels  and  has  included  his 
request  in  the  department's  IRM  plan.  Yet  he  has  had  no  support.  At  this  point  he  is 
concerned  that  his  section  will  be  unable  to  process  permits  that  should  be  issued  in  the 
near  future.  Others  have  attempted  to  develop  their  own  applications.  One  individual 
developed  a registrations  and  billing  database  that  requires  500  pages  of  code.  The 
program  has  grown  so  large  that  he  can  no  longer  support  it,  and  he  has  been  unable  to 
secure  DCS  support  or  hire  a contractor.  His  division  is  small  and  relies  heavily  on  this 
database.  Glitches  in  the  application  thus  have  a significant  impact  on  staff  productivity. 

His  experience  appears  to  be  a common  one  for  other  small  divisions  whose  jobs  are  often 
sandwiched  between  the  work  of  larger  units  and  programs. 

Networking  is  a rapidly  expanding  aspect  of  computing.  Many  of  the  requests  in  the  IRM 
plan  are  network  related.  However  DCS  has  only  four  staff  members  who  are  charged  to 
support  one  or  more  of  the  different  aspects  of  networking  (e.g.  network  operating  systems. 
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wiring,  routers  and  bridges,  application  installations).  Again,  given  limited  support 
resources,  many  programs  have  dedicated  members  of  their  staff,  some  of  whom  are  not 
well-qualified,  to  LAN  installation  and  support.  They  pay  for  expensive  external 
consultants,  or  they  continue  to  operate  with  stand  alone  computers.  Often  these 
installations  have  been  undertaken  without  any  consultation  with  DCS.  in  some  cases, 
these  installations  have  worked  well,  but  in  many  others,  they  have  not  been  set  up  to 
optimize  functionality,  ease  of  maintenance,  or  standard  naming  conventions.  Many  of 
these  solutions  have  resulted  either  in  greater  expense  or  loss  of  productivity  and  more 
frustration  on  the  part  of  division  staff. 

Overall  the  overwhelming  demands  on  limited  resources  have  placed  DCS  as  a division  and 
individual  DCS  staff  members  in  a reactive  rather  than  proactive  position.  For  example, 
one  program  respondent  noted  that  the  department  is  implementing  a new  EDS  accounting 
package  in  the  near  future,  yet  he  has  not  been  notified  about  hardware  (e  g.  PC  vs  3270 
terminal)  or  connectivity  requirements.  Another  respondent  is  a member  of  an  HS1S  user 
group.  He  indicated  that  no  DCS  representative  has  participated  in  any  of  the  group 
discussions.  Clearly  DCS  staff  members  recognize  the  value  of  such  conversations.  They 
simply  haven't  the  time  to  participate  and  consequently,  to  get  a better  understanding  of 
user  needs  beyond  certain  specific  application  requirements. 

Programmer  analysts  are  regularly  approached  by  division  staff  to  assist  not  only  in  the 
maintenance  of  programs,  but  also  in  the  installation  and  maintenance  of  LANs,  the 
provision  of  technical  advice  on  new  hardware  and  software,  and  the  installation  of 
software  applications  and  maintenance  of  PC's.  The  job  description  of  a 
programmer/analyst  doesn't  include  any  of  these  responsibilities.  Although  some 
programmers  have  developed  skills  in  these  areas,  there  is  no  reason  to  expect  them  to  be 
expert,  and  they  are  being  drawn  away  from  their  primary  responsibilities. 

More  generally,  the  scarcity  of  computing  resources  in  DCS  predisposes  division 
personnel  to  trade  on  personal  relationships  with  DCS  staff.  Rather  than  submit  requests 
through  formal  channels,  division  personnel  make  requests  of  individual  programmers  and 
system  support  staff.  This  is  certainly  understandable,  but  it  leads  to  significant  problems  of 
coordination  and  prioritization.  Further,  with  regard  to  HSIS  applications  in  particular,  a 
number  of  applications  are  loosely  integrated.  Thus,  if  changes  are  made  in  one 
application  on  an  ad  hoc  basis,  they  can  cause  unanticipated  problems  in  others.  For 
example,  a significant  number  of  county  health  department  systems  are  not  maintained  by 
the  State  but  are  proprietary.  Data  is  transferred  back  and  forth  in  batch  feeds  Changes  in 
some  program  formats  can  disrupt  these  feeds.  When  the  modifications  are  made  on  a 
personal,  ad  hoc  basis,  it  is  much  more  difficult  to  anticipate  these  interactions.  Overall, 
efforts  to  circumvent  the  formal  channels  create  a self-perpetuating  cycle  where  those  who 
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go  through  formal  channels  have  to  wait  even  longer  and  are  further  tempted  to  go 
informally  through  personal  channels. 

DCS  staff  have  very  limited  opportunities  for  training.  (Less  than  $9000  is  spent  annually 
on  training  in  a $1 .5m  budget  - .06%  of  the  budget.).  As  such,  they  are  not  well  positioned 
to  identify  and  evaluate  new  technologies.  They  are  in  a constrained  position  either  as 
advisors  to  recommend  new  technologies  to  other  divisions  or  to  plan  ahead  to  prepare  for 
the  new  technologies  themselves. 

In  summary,  that  the  DCS  is  understaffed  places  them  in  a largely  reactive  position  and 
fosters  suboptimizing  behaviors  by  other  DEHNR  divisions.  When  divisions  hire 
contractors  or  create  systems  internally,  they  may  create  problems  with  the  pass  off  of 
applications  to  DCS.  They  discourage  effective  integration  of  applications  as  naming 
conventions,  platforms,  etc.  become  more  heterogeneous.  Network  problem  resolution 
becomes  much  more  complex  and  time  consuming.  Some  programmer  analysts  are  pulled 
from  one  set  of  responsibilities  to  another  sometimes  leaving  applications  unfinished  for 
months  at  time.  Finally,  DCS  is  too  busy  to  create  standards  and  monitor  adherence.  In  the 
current  environment  where  standard  policies  and  procedures  aren't  followed,  problems 
associated  with  limited  resources  are  exacerbated  further  by  suboptimizing  behavior  which, 
in  turn,  leads  to  increased  demands  on  DCS  with  a corresponding  increase  in  frustration. 

Recommendations 

The  key  question  is  how  can  DCS,  in  a resource  constrained  environment,  organize  its 
resources  to  provide  better,  more  timely  service  to  DEHNR  divisions.  To  respond  to  this 
question,  any  reorganization  must  result  in  a more  narrowly  focused,  clearly  communicated 
set  of  DCS  responsibilities  and,  if  possible,  should  foster  additional  resources  for  IT  in  the 
larger  department  and  for  DCS  in  particular.  The  following  recommendations  respond  to 
both  the  general  need  to  better  focus  limited  resources  and  to  individual  issues  raised  in  the 
earlier  section. 

Standards  and  Priority  Setting 

I.  A.  Establish  a standing  Information  Resource  Management  Team  (IRM)  that 
would  meet  on  a regular,  perhaps  monthly  basis.  This  group  would  be  composed  of 
respresentatives  from  the  major  DEHNR  divisions,  would  be  chaired  by  the 
Assistant  Secretary  for  Administration,  would  report  regularly  to  DEHNR  senior 
management  with  informational  updates  and  recommendations  for  review  and 
approval.The  DCS  director  would  staff  the  group,  and  the  Deputy  Secretary  would 
be  an  ex  officio  member.  This  team,  with  STRONG  backing  from  senior 
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management  would  be  responsible  for  developing  and  enforcing  all  IT  related 
policies  and  procedures. 

!.  B.  The  Deputy  Secretary  and  Director  of  DCS  should  represent  DEHNR  at  IRMC 
and  selected  SIPS  meetings. 

I.  C.  DCS  should  establish  user  groups  from  DEHNR  divisions  to  provide 
suggestions  and  feedback  on  the  application  of  policies  and  procedures. 

If  any  reorganization  is  to  be  effective,  it  must  be  executed  in  a context  where  applications 
and  systems  are  installed,  developed,  and  maintained  subject  to  departmental  standard 
policies  and  procedures.  Otherwise,  islands  of  automation  will  characterize  the  department 
where  different  divisions  have  different  platforms,  applications,  naming  conventions, 
networks,  etc.  and  access  to  information  from  one  island  to  the  next  will  be  difficult  if  not 
impossible. 

In  part,  the  development  and  application  of  such  policies  and  procedures  will  be  the 
responsibility  of  the  new  Director;  however,  by  itself,  DCS  does  not  have  the  authority  to 
enforce  these  policies.  Support  from  the  most  senior  administrators  will  be  necessary  to 
effectively  enforce  the  such  standards.  Recommendation  I.A  is  intended  to  bring  this  team 
together,  to  establish  a forum  for  discussion,  to  keep  senior  administrators  well-informed 
about  IT  related  issues,  and  to  ensure  enforcement. 

In  addition,  IRMC  and  SIPS  are  agencies  that  are  charged  with  the  development  of  state- 
wide IT  policy  standards.  To  some  degree,  DEHNR  must  simply  accept  their  mandates. 
However,  many  of  the  other  departments  are  fully  represented  in  these  forums  by  their  most 
senior  administrators,  and  these  administrators  have  a significant  impact  on  the  final 
decisions.  DEHNR  should  be  comparably  represented,  relaying  information  back  and  forth. 

Finally,  regardless  of  the  good  intentions  and  preparation,  policies  can  have  unintended 
impacts.  A mechanism  should  be  in  place  that  provides  decision-makers  with  a formal 
mechanism  for  feedback  and  corrective  action.  Recommendation  I.C.  intends  to  provide 
this  mechanism. 

Applications  Development  and  Maintenance 

II.  A.  The  applications  group  should  no  longer  be  housed  entirely  in  DCS.  A number 
of  programmers  and  analysts  should  be  moved  out  physically  to  the  larger  divisions. 
Their  respective  position  budgets  should  also  go  with  them  At  the  same  time,  their 
performance  should  continue  to  be  evaluated  by  the  DCS  Director.  A core  of 
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smaller  divisions  which  can  not  afford  applications  staff  but  have  needs  for 
application  development  and  maintenance,  and  2)  to  provide  quality  control  for 
divisional  application  development.  These  programmer/analysts  would  become 
experts  in  a standard  development  methodology  (e.g.  the  Anderson  Methodology) 
and  assure  that  this  method  is  used  consistently  across  the  divisions.  This  unit  would 
also  be  the  contact  for  the  IRMC  and  for  SIPS.  Finally,  regular  formal  and  informal 
opportunities  (e.g.  brown  bag  lunches,  e-mail  access,  meetings)  should  be  provided 
such  that  programmer/analysts  can  continue  to  benefit  from  one  another’s 
experiences. 

II.  B.  The  specific  location  (i.e.  whether  at  the  division  or  section  level)  and  the 
specific  assignment  of  individual  programmers  and  analysts  would  be  determined  by 
senior  DEHNR  management  in  response  to  recommendations  developed  by  the  IRM 
team.  Currently,  most  programmers  and  analysts  are  associated  with  specific 
applications.  Many  of  the  programmers  have  worked  on  a selected  set  of 
applications  for  a number  of  years  and  are  very  familiar  with  the  logic  and 
idiosyncrasies  of  the  programs.  Given  that  many  of  the  applications  were  written 
before  structured  programming  was  widely  practiced  and  given  limited 
documentation  for  many  of  the  applications,  this  familiarity  is  very  important  and 
should  be  an  important  criteria  in  determining  programmer/analyst  assignments. 

This  recommendation  is  made  for  two  basic  reasons.  First,  it  is  common  knowledge  that 
administrative  divisions  have  a very  difficult  time  securing  incremental  funding.  This  is 
particularly  true  for  DCS  which  has  experienced  a reduction  in  positions  over  the  last  few 
years.  Programs,  on  the  other  hand,  are  more  likely  to  receive  additional  appropriations 
from  the  legislature,  and  many  have  access  to  grants  from  external  agencies  or  can  charge 
fees.  Further,  a number  of  divisions  are  already  paying  contractors  to  help  with 
applications.  In  many  cases,  these  contractors  are  more  highly  paid  than  permanent 
employees.  Over  time,  incremental  revenues  and  budgeted  funds  currently  dedicated  to 
contractors  could  be  applied  to  a permanent  division  applications  staff.  Funding  could  be 
used  to  support  salaries,  the  purchase  of  necessary  hardware  and  software,  and  training. 

Second,  in  the  current  situation,  it  is  clear  that  both  DCS  and  division  staff  are  often 
frustrated.  As  noted  above,  programmers/analysts  are  often  pulled  in  many  directions,  not 
only  to  assist  with  different  applications  but  also  to  help  with  other  IT  related  problems. 
Further,  DCS  programmer/analysts  have  few  opportunities  to  either  formally  or  informally 
anticipate  divisional/programmatic  application  needs.  Moving  to  a division  would  dedicate 
a programmer/analyst  to  the  needs  of  that  division/section.  The  programmer  would  have 
the  opportunity  to  discuss  issues  with  division  personnel  on  a regular,  informal  basis.  In  so 
doing,  he  or  she  would  be  able  to  better  identify  needs  and  make  recommendations  to 
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division  management.  Moreover,  division  management  could  be  sure  that  their  priorities 
are  the  ones  being  addressed.  To  the  degree  that  all  division  applications  can  not  be 
addressed,  it  is  the  prerogative  of  division  management  rather  than  of  DCS  to  determine 
priorities.  This  change  in  the  decision-making  locus  should,  in  itself,  alleviate  some  of  the 
current  frustration. 

The  DCS  Director  would  continue  to  evaluate  performance  for  a number  of  reasons.  First, 
he  or  she  is  better  able  to  assess  the  performance  of  these  positions  which  require  specific 
technical  skill  sets.  Second,  the  DCS  Director  would  also  better  understand  the  direction  in 
which  technology  is  moving  and  can  determine  appropriate  training  requirements.  Finally, 
that  the  programmer/analyst  is  evaluated  by  the  DCS  Director  encourages  adherence  to 
policies  that  are  mandated  by  the  IRMC,  and  therefore  discourages  the  possibility  of  audits 
and  sanctions  for  lack  of  adherence.  In  short,  the  DCS  Director  would  determine  that 
programmer/analysts  across  divisions  would  use  a common  development  methodology,  and 
the  division  director  would  assign  the  development  priorties. 

Importantly,  this  arrangement  requires  regular  communication  between  the  DCS  and 
division  directors.  For  example,  the  DCS  Director  would  identity  and  recommend 
programmer/analyst  training.  The  division  director  would  then  need  to  provide  funding  for 
this  training.  In  turn,  the  DCS  Director  would  honor  the  development  priorities  of  the 
division/section  directors. 

In  general,  divisions  have  seen  their  IT  staff  pulled  into  a central  administrative  division.  At 
the  same  time,  they  have  experienced  a marked  reduction  in  IT  support.  Given  this 
experience  they  have  been  unwilling  to  contribute  resources  beyond  certain  application- 
specific  resources  to  DCS.  This  recommendation  attempts  to  address  these  concerns  and 
encourage  closer,  more  responsive  collaboration  between  division  management  and 
application  staff. 

Network/Telephony  Support 

III.  A.  Wide  Area  Network  administration,  deep  LAN  support,  and  telephony  should 
remain  in  DCS. 

III.  B.  Telephony  support  and  networking  support  should  be  brought  together  under  a 
single  manager  within  DCS. 

III.  C.  LAN  support  in  the  divisions  and  regional  offices  should  remain  physically  located 
in  those  offices  but  should  report  to  the  DCS  director. 
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These  recommendations  are  intended  to  foster  close  coordination  and  collaboration  by 
different  network  support  providers  while  maintaining  a physical  presence  that  is 
responsive  to  site-specific  needs  and  breakdowns.  Telephony  and  WAN  administration 
requires  coordination  across  units  because  associated  technologies  provide  services  which 
cut  across  organizational  and  physical  boundaries.  For  example,  a bridge  will  usually 
connect  several  divisions  often  in  different  locations.  Such  things  as  compatible 
infrastructure  and  protocals  are  essential  if  these  boundaries  are  to  be  effectively  crossed, 
and  a central  administrative  unit  can  better  assure  this  compatibility. 

Digital  networking  and  telephony  have  many  common  installation  and  maintenance  issues. 
At  the  same  time,  technologies  with  both  are  changing  rapidly,  in  many  cases  converging. 
Given  the  fact  that  these  technologies  are  in  flux,  different  well-reasoned  recommendations 
can  be  developed  in  response  to  a division's  request  regarding  communications  technology. 
If  the  division's  representative  receives  different  advice  from  different  units  within  DCS,  he 
or  she  will  usually  leave  confused  and  uncertain  about  he  best  course  of  action.  With  both 
networking  and  telephony  support  reporting  to  the  same  manager,  differing  responses, 
incompatible  installations,  etc.  can  be  minimized.  Personnel  in  the  same  unit,  could  develop 
a common  set  of  recommendations  or  actions  for  such  things  as  wiring  and  network 
topologies. 

Deep  LAN  support  and  perhaps  some  regular  networking  classes  should  be  provided 
centrally  for  on-site  LAN  administrators.  It  is  apparent  that  these  administrators  vary 
markedly  in  both  their  ability  and  in  their  training.  In  many  cases,  operational  managers 
underestimate  the  skills  necessary  to  effectively  setup  and  manage  a network  of  any  size. 

As  a result,  they  sometimes  assign  staff  to  LAN  administration  who  are  not  up  to  the  job. 
And  even  for  those  who  are  well-skilled,  problems  can  crop  up  that  are  beyond  their  general 
level  of  competence.  This  central  resource  could  help  ameliorate  problems  associated  with 
the  variation  in  skills  and  provide  answers  to  complex  networking  problems. 

Finally,  LANs  have  become  key  in  the  day-to-day  operations  of  many  DENHR  sections. 
Often,  work  stops  when  the  LAN  goes  down.  This  critical  role  thus  requires  that  someone 
be  on-site  to  respond  quickly  in  the  event  of  a breakdown.  At  the  same  time,  the  actual 
setup  of  a LAN  (e.g.  file  naming,  directory  structures)  must  often  be  coordinated  to  assure 
the  effective  operation  of  applications  that  rely  on  files  located  at  different  sites  and  on 
different  LANs.  In  addition,  any  LAN  administrator  should  be  expected  to  follow  a number 
of  good,  standard  practices  (e.g.  following  regular,  timely  backup  procedures).  Under  the 
current  fragmented  organization,  both  setups  and  practices  vary  substantially  thereby 
increasing  application  maintenance  efforts  and  placing  important,  sometime  mission  critical 
data,  at  risk.  Recommendation  III.C.  is  intended  to  address  these  concerns. 
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Other  DCS  services 


IV.  A.  DCS  should  establish  a data  administration  function.  At  a minimum,  a data 
base  administrator  should  be  hired  who  has  strong  DBMS  skills,  good  data 
modeling  skills,  and  is  sensitive  to  the  political  realities  of  such  a position. 

IV.  B.  Systems  security  should  continue  to  be  housed  in  DCS.  However,  procedures 
for  password  administration  should  be  reviewed,  and  some  responsibilities  may  be 
passed  to  divisions. 

IV.  C.  DCS  should  establish  a help  desk  that  has  two  principle  responsibilities:  1 ) to 
act  as  a clearing  house  for  DEHNR  divisions'  computer  users.  This  help  desk  would 
be  a single  point  of  contact  for  all  inquires  and  would  direct  inquiries  to  the 
appropriate  people  in  DCS,  SIPS,  or  to  IT  personnel  in  the  operating  divisions;  and 
2)  to  provide  deep  support  for  IT  personnel  in  the  divisions. 

IV.  D.  DCS  should  establish  a planning/training  coordinator  function.  An  existing 
DCS  staff  member  might  be  assigned  to  this  on  a half-time  basis.  This  function 
would  evaluate  changing  technologies,  make  recommendations  to  the  Director  about 
DCS  positioning  and  adoption  of  new  technologies,  and  develop  the  IRMC  plan. 
This  function  would  also  determine  DCS  (and  where  desired,  divisional 
programmer/analyst)  training  requirements,  and  coordinate  with  SIPS  and  other 
vendors  to  provide  classes. 

IV.  E.  DCS  would  provide  a DEHNR  disaster  recovery  function  which  would 
coordinate  with  the  SIPS  disaster  recovery  function. 


Recommendations  IV.  A,  B,  C,  and  E all  address  functions  where,  through  a centralization 
of  services,  redundancies  can  be  reduced  and  information  can  be  more  readily  secured  and 
accessed  by  authorized  individuals  across  the  department.  Effective  data  administration  is 
essential  to  acquire  and  store  relevant  data  and  to  retrieve  that  data  and  assure  accurate, 
reliable  reporting.  A central  site  for  security  supports  appropriate  access  to  authorized 
individuals  across  departmental  applications  and  systems  using  a single  password.  A help 
desk  as  a central  contact  assures  that  departmental  requests  are  correctly  routed  to  all  the 
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appropriate  support  people,  and  a central  disaster  recovery  function  assures  that  all  critical 
information  and  applications  are  saved  regardless  of  the  practices  of  individual  divisions  or 
programs.  The  planning/training  function  would  enable  DCS  and  IT  people  in  other 
divisions  to  better  anticipate  and  perpare  for  rapidly  changing  technologies.  It  would  also 
satisfy  requirements  of  other  state  agencies  like  the  IRMC. 


Conclusion 

Critical  to  the  success  of  DCS  is  the  support  of  the  senior  DEHNR  management  from  the 
Secretary  to  the  Assistant  Secretaries.  They  must  give  the  DCS  Director  a clear 
understanding  of  their  expectations  and  provide  forums  for  regular  updates  on  computing 
issues.  To  do  this,  the  DEHNR  senior  management  must  have  a basic  understanding  of 
strategic  IT  management  issues.  With  this  in  mind,  it  would  be  very  useful  for  senior 
management  to  receive  a course  that  gives  an  overview  of  these  issues.  A number  of  good 
courses  are  available  and  can  be  provided  off  site  or  in  house.  Training  and  new  staff  will 
be  necessary  to  provide  the  functions  recommended  above.  Finally,  a commonly  cited 
complaint  is  the  time  taken  to  process  administrative  paperwork.  Senior  leadership  might 
initiate  a paperwork  review  for  IT  processing  to  identify  opportunities  to  streamline 
administrative  information  requests. 
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North  Carolina  State  Government  Information  Resources  Management  Commission  (IRMC) 
Long-term,  Statewide  Technology  Planning  and  Implementation  Issues 

Major  Observation 

The  state  generally  is  not  prepared  to  implement  satisfactorily  large-scale  information  technology 
projects  on  a consistent  basis,  whether  internally  developed  or  externally  contracted.  If  the  IRMC 
is  to  serve  the  leadership  position  for  information  technology  and  telecommunications  articulated 
in  its  enabling  legislation,  it  must  focus  state  government’s  attention  on  the  issues  described 

below. 

Background 

This  conclusion  is  reached  as  a result  of  (a)  reviewing  the  status  of  major  systems  implementation 
efforts  through  the  IRMC’s  ongoing  periodic  project  reporting  procedures,  (b)  evaluating  agency 
biennial  technology  plans,  and  © completing  the  Statewide  Technology  Strategies  and  Initiatives 
document.  Specifically,  these  activities  provided  clear  evidence  that  some  major  and  very 
important  systems  implementation  projects  are  not  being  performed  with  the  degree  of  success  in 
cost,  quality  and  timeliness  expected  of  such  endeavors.  One  cause  of  this  situation  is  the  agency 
technology  plans  indicate  that  the  foundation  capabilities  in  personnel  resources  and  quality 
assurance  practices  for  accomplishing  large,  complex  projects  are  inadequate. 

Specific  Deficiencies 

Definitive  shortcomings  that  must  be  rectified  for  the  state  to  be  able  to  introduce  new  and 
enabling  technologies  and  implement  large-scale  applications  systems  more  successfully  are  listed 

as  follows: 

1 . Lack  of  quality  management  practices  and  procedures,  especially  the  current  limited  use 
of  standard  systems  development  life  cycle  methodologies  for  planning  and  managing 
projects. 

2.  Scarcity  of  project  management  expertise  and  experience  necessary  to  implement 
large-scale,  sophisticated  systems. 

3.  Insufficiency  of  personnel  with  the  technical  skills  required  to  design,  install,  and 
maintain  applications  systems  developed  using  components  of  modern  technologies. 

4.  Limited  senior  program  management  involvement  in  the  planning  for  and  employment 
of  modem  technologies  to  improve  significantly  the  operations  of  their  organizations, 
particularly  the  use  of  technologies  to  provide  more  and  better  services  at  reduced  total 
costs. 

5.  Continued  use  of  isolated,  agency  focused  funding  mechanisms  and  developmental 
approaches  for  implementing  systems  when  the  applications  have  statewide,  multi- 
agency implications. 

6.  Lack  of  adequate  planning  for  data  security  and  disaster  recovery. 


Recommendations 


Unfortunately,  the  state  has  reached  a position  where  the  situation  is  of  such  gravity  that  the 
continuance  of  present  practices  or  the  refinement  of  current  procedures  will  not  address 
adequately  the  problems  and  challenges.  Accordingly,  corrective  measures  must  be  far-reaching 
and  dramatic.  Specific  recommendations  are  highlighted  below: 

1 . The  IRMC  must  ensure  that  the  leadership  of  state  government  is  aware  of  the  serious 
problems  and  challenges  by  communicating  them  in  a manner  that  is  clear,  concise,  and 
unambiguous. 

2.  Senior  agency  management  must  take  a more  active  role  in  the  overview  of  technology 
implementation  endeavors.  Agencies  have  tremendous  investments  in  hardware,  data 
and  personnel  resources,  and  technology  has  become  an  indispensable  component  in  the 
delivery  of  services  and  the  performance  of  business  functions.  Specifically,  agency 
management  must  see  that: 

• Quality  management  practices  and  procedures,  including  commonly 
recognized  system  development  life  cycle  methodologies  and  software 
quality  engineering,  are  implemented  in  a timely  manner. 

• Funding  is  provided  for  the  education  and  training  of  technical  and 
program  personnel  involved  in  the  development  and  employment  of 
information  technology. 

• Projects  are  staffed  with  the  appropriate  number  of  personnel  and  staff 
must  possess  the  necessary  project  management  and  technical  skills  and 
expertise  to  complete  the  work  in  the  assigned  time  period  and  with  the 
expected  results. 

• The  necessary  security  and  disaster  recovery  safeguards  are  implemented  at 
the  agency  level. 

3.  OSC/IRM  staff  must: 

• Develop  guidelines,  provide  advice  and  give  assistance  to  the  agencies  in 
developing,  implementing,  and  sustaining  quality  management  programs. 

• Determine  a comprehensive  curriculum  of  study  and  assist  in  arranging 
cost-effective  instruction  for  updating  the  skills  and  improving  the 
management  expertise  of  technical  staff  and  acquainting  program  personnel 
with  the  necessary  awareness  of  the  capabilities  and  uses  of  technology  for 
accomplishing  business/program  objectives. 

• Provide  leadership  in  the  state  wide  project  to  develop  broad-based 
security  capabilities,  techniques  and  procedures,  including  software 
resources. 

• Consider  the  needs  for  and  benefits  provided  by  the  establishment  of  a 
central  source  of  technical  skills,  project  management  experience,  and 
project  assessment  expertise  to  facilitate  the  accomplishment  of  the  design 
and  installation  of  larger,  more  technically  complex  and/or  functionally 
sophisticated  applications  systems,  particularly  those  implementation 


projects  involving  new  technologies  and/or  having  statewide  or  multi-agency 
implications. 


Statewide  Technology  Issues 

Information  Resource 
Management  Commission 

March  7,  1994 

Office  of  the  Slate  Controller  I Information  Resource  Management 


Some  of  you  may  feel  uncomfortable  with  my  forthcoming 
comments.  The  evidence  supporting  them  is  very  strong.  I do  not 
bring  good  news,  and  the  answers  are  neither  easy,  simple  nor 
inexpensive. 

Our  situation  is  pervasive  and  chronic  and  it  will  take  time,  focused 
attention  and  an  all  inclusive  effort  to  rectify  it.  Many  factors 
contributed  to  our  getting  to  this  undesirable  position,  and  all  of  us 
must  assume  the  responsibility  for  extracting  ourselves  from  it. 


Statewide  Technology  Issues 

Bases  for  Findings 

1991-  ‘92  GPAC  Study 

Preparation  of  Statewide  Technology  Strategy  and 
Initiatives  document 

Review  of  agencies’  biennial  technology  plans 
Monthly  review  of  major  systems  implementation  projects 

Office  of  the  State  Controller 2 Information  Resource  Management 


1.  The  1991 -’92  GPAC  study  was  reviewed  for  two  reasons.  First, 
it  provides  a reference  point,  or  shapshot,  of  the  situation  about 
two  years  ago.  Second,  it  serves  as  a verification  of  the  problems 
and  challenges  that  have  been  identified  or  suspected  as  a result  of 
other  activities  performed  by  the  OSC/IRM  staff. 

2.  The  development  of  the  Strategy  and  Initiatives  document 
provided  a clear  vision  of  the  use  of  technology  to  make 
government  more  responsive  to  the  needs  of  citizens  and  more 
accountable  for  performance  and  expenditures. 

3.  The  review  of  agencies’  biennial  technology  plans  offered  a 
revealing  insight  regarding  the  efforts  and  strategies  for  the 
deployment  and  use  of  technology  and  the  management  of  technical 
resources  by  each  of  the  23  executive  branch  agencies. 

4.  In  July  1993,  the  IRMC  approved  the  procedures  and  policies  for 
the  quality  assurance  and  progress  reporting  for  major  systems 
development  projects.  We  have  received  reports  on  about  a dozen 
projects  each  month.  If  you  turn  to  tab  8 of  your  material  for  this 
month,  you  will  see  that  over  one-half  of  the  projects  merit 
attention  - a first-time  event. 


Statewide  Technology  Issues 

Fundamental  Observation 


The  state  is  not  prepared  to  implement 
satisfactorily  either  new  or  conventional 
technology  as  a large-scale  endeavor  on  a 
consistent  basis 


Office  of  the  State  Controller  3 Information  Resource  Management 


For  a variety  of  reasons,  the  state  is  not  prepared  to  complete 
successfully,  on  a consistent  basis,  large-scale  technology  projects  - 
either  employing  older  or  new  technology  and  whether  the  work  is 
completed  by  internal  personnel  or  by  external  contractors.  We 
simply  are  not  in  position  to  perform  with  any  degree  of  certainty 
for  success  the  more  complex  and  involved  technology  projects 
described  in  the  Governor’s  budget  under  Tab  7 of  the  meeting 
material  and  expected  from  the  major  studies  (e.g.,  NCCAN,  CJTN 
and  voter  registration)  nearing  completion. 

In  the  past,  for  some  large  technology  related  endeavors,  we  have 
been  successful.  The  initial  implementation  of  the  NCIH  is  a prime 
example.  For  the  present,  on  an  ongoing  and  consistent  basis,  this 
capability  does  not  exist  today. 


Statewide  Technology  Issues 

Areas  Experiencing  Improvements 

• Appreciation  for  coordination  of  systems  and  work  efforts 

• Purchasing  and  procurements 

• Initial  project  reporting 

• Communications  standards 

• Statewide  strategy  and  initiatives 

Office  of  the  State  Controller  4 Information  Resource  Management 

Since  the  creation  of  the  IRMC,  significant  progress  has  been 
achieved  in  certain  areas.  These  are  listed  on  this  transparency. 


Statewide  Technology  Issues 

Areas  of  Insufficient  Progress 


• Quality  assurance,  including  systems 
development/documentation  methodology 

• Human  resource  development 

- Upgrading  technical  skills 

- Improving  management/supervisory  capabilities 

• Disaster  recovery  for  local  hardware/software  resources  and 
business  processes 

• Implementation  of  new  and  enabling  technologies  to  meet 
ever-increasing  and  more  complex  business  and  program 
demands 
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The  first  two  items  on  this  transparence  are  necessary  prerequisites 
for  any  organization  to  be  able  to  implement  technology  in  a 
consistently  successful  manner.  These  deficiencies  were  identified 
repeatedly  in  the  GPAC  findings,  and  we  may  be  in  worse  shape 
today  regarding  them  than  during  the  time  period  of  GPAC. 

With  respect  to  the  last  item,  governmental  organizations,  at  all 
levels,  must  improve  their  performance  dramatically  to  retain  public 
confidence  and  increase  the  satisfaction  of  citizens  for  the  services 
provided.  The  appropriate  and  innovative  use  of  modem  and 
emerging  technology  for  information  management  and 
communications  is  absolutely  essential  for  the  achievement  of  this 
objective. 


Statewide  Technology  Issues 

Major  Contributing  Factors 

Inadequate  involvement  by  senior  business/program 
management  of  agencies  in  the  leadership  of  the  technology 
area,  including: 

- Funding  for  education  and  training 

- Project  management  and  oversight  of  department  activities 

- Quality  assurance,  disaster  recovery  and  security 

- Investments  in  strategic  and  modem  technology 

Absence  of  a statewide  organization  for  accomplishing 
major  technology  projects 
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Over  the  past  decade,  information  technology  and 
telecommunications  has  clandestinely  and  insidiously  become  an 
increasingly  important  part  of  the  operations  of  government.  Now, 
computing  has  become  a strategic  resource  for  state  and  local 
governments,  with  priceless  data  and  expensive  hardware,  software, 
and  personnel  investments.  Accordingly,  senior  managers  can  not 
abdicate  their  responsibilities  in  this  area.  More  important,  they  can 
no  longer  delegate  computing  and  communications  to  the 
technologists. 

The  second  point  is  a dramatic  departure  from  present  practices, 
and  it  involves  several  considerations.  The  most  important  is 
whether  the  current  fragmented  structure  can  provide  the  critical 
mass  of  knowledge,  experience  and  skills  and  economicies  of  scale 
necessary  to  perform  major  systems  development  projects 
efficiently  and  reliably,  while  facilitating  the  conversion  of  our 
technical  workforce  to  the  new  and  enabling  technologies. 


Statewide  Technology  Issues 

Recommendations 


• The  leadership  of  state  government  must  be  made  aware  of 
the  present  serious  situation 

• Senior  agency  business/program  management  must  take  a 
more  active  role  in  the  leadership  and  oversight  of 
technology  departments  and  system  implementation  projects 

• The  OSC/IRM  staff  must  provide  direction,  advice  and 
assistance  in  critical  areas  necessary  to  rectify  the  problems 
and  address  the  challenges 
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The  details  of  these  recommendations  are  presented  in  the  meeting 
material  under  Tab.  3. 

1.  Briefly,  senior  government  officials  (not  technologists  or  MIS 
Directors)  must  be  informed  of  their  responsibilities  for  exercising 
the  appropriate  leadership  for  the  investment,  implementation  and 
employment  of  technology  in  their  agencies  and  departments.  As  a 
result  of  this  increased  attention,  the  directions  to,  expectations 
from  and  roles  of  the  senior  agency  technical  officials  may  change, 
probably  quite  dramatically. 

2.  Senior  agency  officials  (not  just  the  technologists)  must  become 
personally  involved  in  the  management  and  performance  of  their 
technical  departments  or  divisions.  The  problems  presented  are 
more  management  oriented  than  technical. 

3.  The  OSC/IRM  staff  and  SIPS  can  help,  and  it  will  in  the  area 
indicated;  however,  under  the  present  organizational  structure  for 
implementing  systems,  agencies  have  the  ultimate  responsibility  for 
the  readiness  and  capabilities  of  technology  staffs  to  accomplish 
systems  implementation  efforts. 


Appendix  d 


State  of  North  Carolina  Information  Resource  Management  Commission 
guidelines  and  Procedures  for  Resource  Acquisition,  Periodic  Progress 
(Status)  Reporting  for  Systems  Implementation  Projects,  and  Quality 
Management  for  systems  Implementation  Projects 


State  of  North  Carolina  Information  Resources  Management  Commission  Guidelines  and 
Procedures  For  Resource  Acquisition,  Periodic  Progress  (Status)  Reporting  for  Systems 
Implementation  Projects,  and  Quality  Management  for  Systems  Implementation  Projects 

I.  Resource  Acquisition 

A.  Overview  Explanation 

Resources  purchased  for  implementing  technology  can  involve  many  forms,  including  hardware, 
software,  personnel  services  (especially  for  unique,  esoteric  skills  or  experiences,  but  often  to 
obtain  regular  staffing  for  leveling  peaks  and  valleys  of  work  loads),  and  consultative  services. 
While  many  procurements  originate  as  natural  outcomes  or  associations  with  systems  or 
technology  implementation  projects,  some  are  initiated  as  stand-alone,  isolated  initiatives.  In 
addition,  purchase  orders,  requests  for  proposals  (RFPs),  invitation  for  bids  (IFBs),  sole  source 
purchases  and  other  practices  and  documents. 

The  guidelines  and  procedures  provided  in  this  manual  are  intended  to  be  congruent  with  those  of 
the  Division  of  Purchase  and  Contract  of  the  Department  of  Administration  (P&C).  In  fact,  they 
follow  closely  the  procedures  that  have  been  used  on  an  informal  basis  over  the  past  few  months. 
The  intentions  of  the  guidelines  and  procedures  in  this  manual  are  to  present  a consistency  of 
operations  for  review,  evaluation  and  approval,  while  offering  the  flexibility  necessary  for 
accommodating  the  continually  evolving  technical,  business/program  and  competitive 
environment  under  which  we  must  operate,  as  well  as  the  unique  characteristics  of  each 
procurement. 

B.  Summary  of  Thresholds 

Type  of  Resource  Threshold  Processing 

Hardware  and/or  Software  Equal  to  or  greater  than  $10,000  Will  be  forwarded  to  IRMC 

staff  for  review.  Items  greater 
than  $2m  must  be  brought 
before  the  IRMC.  Others  may 
be  brought  before  the  IRMC, 
at  the  discretion  of  its  staff. 

If  agreement  cannot  be 
reached  between  agency/ 
departmental  personnel  and 
IRMC  staff,  the  Chair  of  the 
IRMC  will  select  the 
appropriate  reviewing 
authority  for  a decision. 


Type  of  Resource 


Threshold 


Consulting  and  Contractual 
Services 


Equal  to  or  greater  then  $500,000 
- total,  long-term  purchase  so  that 
a procurement  is  not  arbitrarily 
segmented  into  separate  purchase 
actions  to  avoid  exceeding  a 
review/reporting  threshold. 

All  planning/direction  setting 
projects,  regardless  of  cost  or  type 
of  contract,  must  be  reviewed. 
Service  agreements/contract 
renewals  are  excluded  from  the 
IRMC  review. 


Processing 

Will  be  forwarded  to  the 
IRMC  staff  for  review.  Items 
equal  to  or  greater  than  $2m 
must  be  brought  before  the 
IRMC,  at  the  discretion  of  its 
staff.  If  agreement  cannot  be 
reached  between  agency/ 
department  personnel  and 
IRMC  staff,  the  Chair  of  the 
IRMC  will  select  the 
appropriate  reviewing 
authority  for  a decision. 
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STATE  OF  NORTH  CAROLINA 
INFORMATION  RESOURCE  MANAGEMENT  COMMISSION 


IRMC  RESOURCE  ACQUISITION  REVIEW  SHEET 
PROJECT  IDENTIFICATION: 


AGENCY  NAME: SUBMITTER’S  NAME: 

SUMMARY  OF  TYPE  OF 

ITEMS  BEING  PURCHASED: DATE  SUBMITTED:  _ 

PURCHASE  AMOUNT  ($): DATE  RECEIVED 

(IRMC  OFFICE): 

P & C CONTROL  NUMBER: 


IRMC  STAFF  CLASSIFICATION: 


APPROVED  - Authorized  by (See  comments,  if  appropriate.) 


REFERRED  - (See  comments  below.) 


IRMC  STAFF  COMMENTS: 


REFERRAL  INFORMATION: 


Referred  to  the  organization(s)  listed  below  for  further  detailed  review,  analysis  and  evaluation. 


Resource  Acquisition 

Examples  of  Specific  Points  to  Address  - Uses  as  Applicable 
Resource  Acquisition: 

[ 1 ] Business/Program  Objectives  and  Benefits:  Are  the  following  clearly  stated, 
including: 

A.  Objectives 

B.  Capabilities 

C.  Functions 

D.  Features 

E.  Results 

F.  Benefits  (tangible  and  intangible)  including  a payback/break-even  analysis 
Note:  An  example  of  a payback/break-even  analysis  will  be  developed. 

G.  Business  Case  - Program/Process  Re-engineering 

[2]  Funding:  Is  the  funding  sufficient  to  accomplish  the  objectives  and  deliver  the 
expected  benefits  and  results? 

[3]  Project  Management  and  Organization:  Are  the  following  appropriate  and 
sufficient  to  accomplish  the  objectives  and  deliver  the  expected  benefits  and  results: 

A.  Work  plans 

B.  Organization  Structure 

C.  Quality  Management  Plans 

D.  Staffing  Plans 

[4]  Technical  Architecture:  Is  the  Technical  Architecture  congruent  with: 

A.  Agency/department  plans 

B.  Directions  of  the  IRMC 

[5]  Other: 

A.  Interconnectivity 

B.  Disaster  Recovery 

C.  For  Imaging  Systems,  Audit  Compliance  (if  financial  project)  and 
Historical  Record  Retention  Compliance 

II.  Periodic  Project  Progress  (Status)  Reporting 

A.  Overview  Explanation 

The  primary  objective  of  project  progress  reporting  is  to  inform  the  IRMC,  on  a regularly 
scheduled  basis,  of  the  overall  status  and  general  position  of  major  systems  or  technology 
implementation  projects  over  which  has  overview  responsibility  per  state  statutes.  This  practice 


enables  the  members  of  the  IRMC  to  monitor,  at  least  on  a summary  level  and  at  least 
periodically,  the  progress  of  each  major  systems  or  technology  implementation  project  as  it 
progresses  to  completion,  and  goes  into  production,  with  the  paramount  objectives  of  finishing  on 
time,  within  budget  and  providing  the  expected  business/program  results  and  benefits. 

It  is  envisaged  that  the  preparation  of  the  submission  of  the  periodic  project  progress  report  by 
cognizant  personnel  of  the  sponsoring  agency/department  will  follow  the  normal  tasks  associated 
with  developing  internal  weekly  or  bi-weekly  project  progress  reports.  That  is,  the  periodic  report 
is,  in  many  respects,  a consolidation  and  summarization  of  the  internal  reports  prepared  for 
agency/department  management.  In  fact,  the  format  of  the  report  specified  in  this  manual  has  been 
derived  from  weekly  internal  reports  which  have  been  used  by  several  agencies/departments  over 
the  past  few  years. 


To  provide  consistency  of  reporting  and  to  facilitate  review  and  evaluation  by  the  members  of  the 
IRMC,  the  reporting  outline  and  the  example  project  GANTT  chart  (including  person  time  work 
effort  data)  given  in  this  section  is  expected  to  be  followed.  Charts  produced  by  other  projects 
management  software  may  be  acceptable,  as  long  as  they  contain  the  required  information  in  a 
reasonably  similar  format.  Of  course,  each  project  presents  particular  issues,  problems,  challenges 
and  opportunities  as  it  progresses  through  its  natural  implementation  life  cycle.  Accordingly, 
agency/department  management  has  considerable  discretion  in  selecting  the  appropriate  items  for 
presentation  to  the  IRMC.  The  IRMC  and  agency/department  officials  have  a joint,  common 
interest  in  ensuring  that  each  project  is  completed  successfully.  Agency/department  officials, 
therefore,  have  a clear  responsibility  for  the  accuracy,  timeliness  and  relevancy  of  information 
submitted  to  the  IRMC  in  the  periodic  project  progress  report. 

B.  Summary  of  Thresholds 


Project  Size/Characteristics 

Less  than  $1  million  - total,  long-term 
expenditures  - and  which  involves  new 
technology,  has  statewide  implications, 
represents  a situation  of  unusual  risk,  or  is 
considered  a major  systems  or  technology 
implementation  endeavor 

Equal  to  or  greater  than  $ 1 million  (internal 
plus  outside)  - total,  long-term  expenditures 
- and  be  considered  a major  systems  or 
technology  implementation  endeavor 


Processing 

The  need  for  periodic  project  progress 
(status)  reporting  will  be  determined  by  the 
sponsoring  agency/department  personnel  in 
conjunction  with  the  IRMC  staff,  the  Chair 
of  the  IRMC  will  select  the  appropriate 
reviewing  authority  for  a decision 

The  need  for  providing  periodic  project 
progress  (status)  reporting  will  be 
determined  by  the  IRMC  staff,  in 
conjunction  with  the  sponsoring 
agency/department.  If  agreement  cannot  be 
reached  between  agency/department 
Equal  to  or  greater  than  $2  million  (internal 


plus  outside)  - total  long-term  expenditures  - 
and  be  considered  a major  systems  or 
technology  implementation  endeavor 


personnel  and  IRMC  staff,  the  Chair  of  the 
IRMC  will  select  the  appropriate  reviewing 
authority  for  a decision 

Must  provide  periodic  project  (status) 
reporting 


II.  Periodic  Project  Progress  (Status)  Reporting  (continued) 

C.  Reporting  Frequency 

The  frequency  of  reporting  must  be  determined  by  considering  a variety  of  factors,  and  each 
project  must  be  evaluated  on  the  merits  of  its  individual  situations  and  circumstance.  Complexity, 
size,  exposure  to  technical  and/or  business/program  risks  and  duration  are  some  of  the  elements 
that  must  be  considered.  The  intent  is  to  appraise  the  IRMC  in  a time  frame  that  allows  it  to  be 
fully  cognizant  of  the  status  of  each  project,  while  allowing  it  time  to  react  to  potential  adverse 
situations  within  its  purview. 

Periodic  project  progress  reports  are  anticipated  to  be  provided  to  the  IRMC  by  responsible 
agencies/departments  on  either  monthly,  bi-monthly,  or  quarterly  basis.  Project  of  durations  of  12 
months  or  less  are  expected  to  be  reported  to  the  IRMC  monthly  or  bi-monthly,  while  projects  of 
longer  duration  are  expected  to  be  reported  bi-monthly  or  quarterly.  The  reporting  frequency  for 
each  project  will  be  determined  by  the  IRMC  staff,  in  conjunction  with  agency/department 
officials.  If  agreement  cannot  be  reached  between  agency/department  personnel  and  IRMC  staff, 
the  Chair  of  the  IRMC  will  select  the  appropriate  reviewing  authority  for  a decision. 
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STATE  OF  NORTH  CAROLINA 
INFORMATION  RESOURCE  MANAGEMENT  COMMISSION 

IRMC  PROJECT  PROGRESS  (STATUS)  REVIEW  SHEET 

PROJECT  IDENTIFICATION: 

AGENCY  NAME: PERIOD  COVERED: 

PROJECT  NAME: DATE  SUBMITTED: 

PROJECT  SPONSOR: DATE  RECEIVED 

(IRMC  OFFICE): 

IRMC  STAFF  CLASSIFICATION: 

EXEMPLARY  - Project  appears  to  be  in  excellent  shape. 

ROUTINE  - No  significant  issues/problems  identified  (see  comments  below.) 

NEEDS  A TTENTION  - Major  actual  or  potential  issues/problems  that  may  impact  adversely  the 

progress,  costs  and/or  results  (see  comments  below.) 

NOT  CLASSIFIED  AT  THIS  TIME  (See  comments  below.) 


IRMC  STAFF  COMMENTS: 


REFERRAL  INFORMATION: 


Referred  to  the  organization(s)  listed  below  for  further  detailed  review,  analysis,  and  evaluation. 


Periodic  Project  Progress  (Status)  Report  Outline 


Agency  Name: 

Project  Name: 

Project  Sponsor: 

I.  Progress  Report  Summary: 

Highlight  very  succinctly  the  overall  status  of  the  project,  particularly  with  respect  to  its 
completion  on-time,  on-budget  and  delivering  the  expected  results  and  benefits. 
Comments  should  be  made  regarding  actual  completion  dates  versus  planned  completion 
dates  for  major  milestone  points  and  major  deliverables  completed/provided  versus 
planned  deliverables.  A ttach  a one-page  Project  GANTT  Chart  indicating  project  status. 
The  GANTT  chart  must  follow  the  format  prescribed for  it,  including  the  giving  of  actual 
person  times  (person  days  or  person  weeks)  versus  budget,  estimates  to  complete  (person 
times)  and  variance  (person  times)  by  major  project  task  or  segment  and  or  the  total 
project.  The  planned  and  actual  position  of  each  major  project  task  or  segment  should  be 
shown  graphically  by  time. 

II.  Accomplishments  This  Period: 

Provide  a bullet  point  summary  of  key  accomplishments  or  the  month  organized  by  active 
work  plan  segment. 

III.  Issues  Requiring  Management  Attention: 

Provide  a bullet  point  summary  of  each  significant  issue  that  has  arisen  and  its 
conclusion/resolution,  if  resolved  Issues  should  be  organized  by  order  of  importance. 

Each  of  these  issues  should  be  carefully  considered  to  determine  the  possible  impact  on 
the  project  as  a whole,  particularly  the  impact  on  completing  the  project  on-time,  on- 
budget  and  delivering  the  expected  results  and  benefits. 

IV.  Plans  for  Next  Period: 

Provide  a bullet  point  summary  of  significant  activities  planned for  the  next  period 
organized  by  active  work  plan  segment. 

V.  Dates  of  Last  and  Next  Quality  Management  Review 

Note  the  date  of  the  project 's  last  Quality  Management  Review. 

Note  the  date  of  the  project  ’ s next  expected  Quality  Management  Review. 


Preparer’s  - 

Name: 

Telephone  Number: 
Period  Covered: 


Periodic  Project  Progress  (Status)  P 
Example  GANTT  Clwrt 


STATE  OF  NORTH  CAROLINA 
INFORMATION  RESOURCE  MANAGEMENT  COMMISSION 
GUIDELINES  AND  PROCEDURES  FOR  RESOURCE  ACQUISITION, 

PERIODIC  PROGRESS  (STATUS)  REPORTING  FOR  SYSTEMS  IMPLEMENTATION  PROJECTS, 
AND  QUALITY  MANAGEMENT  FOR  SYSTEMS  IMPLEMENTATION  PROJECTS 


III.  Quality  Management 


A.  Overview  Explanation 

Quality  Management  applies  to  the  policies,  practices  and  procedures  emphasized  to  ensure  major  systems  or  technology 
implementation  projects  are  completed  on  time,  within  budget  and  the  expected  business/program  results  and/or  benefits 
are  delivered  or  achieved.  The  concept  followed  in  this  manual  focuses  on  the  building  in  of  quality  from  the  planning  of  a 
project  through  its  completion  — quality  is  a continuous  process,  not  an  incremental  or  occasional  activity. 

The  quality  management  process  involves  the  identification  of  a series  of  checkpoints  throughout  the  project,  where 
detailed  reviews  are  performed  and  findings  are  documented  and  presented  to  the  IRMC.  Sample  checkpoints  are  offered 
in  an  addendum  to  this  manual  (a  separate  document),  and  checklists  of  items  normally  requiring  review  and  evaluation 
are  given  for  each  of  those  checkpoints.  As  each  project  is  unique  in  many  respects,  including  business/program 
objectives,  technical  issues,  organizational  considerations  and  political  environments,  the  specific  placement  of 
checkpoints  within  each  project’s  life  cycle  and  the  scope  and  focus  of  precise  items  to  be  reviewed  must  be  determined  on 
a project-by-project  basis.  The  extensive  documentation  contained  in  an  addendum  to  this  manual  (a  separate 
document),provides  useful  guidelines  and  examples  for  performing  the  tasks  of  determining  checkpoints  and  specifying 
items  for  detailed  scrutiny,  evaluation  and  reporting.  In  fact,  if  needed,  more  detailed  checklists  are  included  with  the 
systems  development  life  cycle  methodology'  used  by  many  of  the  large  state  agencies/departments,  and  the  summary 
checklists  contained  in  the  addendum  to  this  manual  are  cross-referenced  to  them. 

Project  quality  management  check  points  and  essential  items  to  be  reviewed  will  be  determined  by  sponsoring 
agency/department  personnel,  in  conjunction  with  IRMC  stall'.  If  agreement  cannot  be  reached  between 
agency/departmenl  personnel  and  IRMC  staff,  the  Chair  of  the  IRMC  will  select  the  appropriate  reviewing  authority  for  a 
decision. 

A paramount  concept  employed  in  the  quality  management  process  is  that  all  reviews  will  be  conducted  by  knowledgeable, 
experienced  personnel  not  directly  involved  in  the  project.  If  a project  is  being  conducted  and/or  managed  by  an  outside 
organization,  contractor  personnel  may  perform  the  review,  if  the  reviewing  personnel  are  independent  of  the  protect.  As 
most  major  systems  or  technology  implementation  projects  performed  in  state  government  and  requiring  quality 
management  reporting  to  the  IRMC  involve  complex  issues,  it  is  assumed  that  agenev/department  employees  and/or  IRMC 
staff"  will  not  normally  perform  these  reviews,  without  outside  participation. 

B.  Summary  of  Thresholds 


Project  Size 

Equal  to  or  greater  than  SI  million  (internal  plus  outside) 
- total,  long-term  expenditures  — and  be  considered  a 
major  systems  implementation  endeavor 


Equal  to  a greater  than  $2  million  (internal  plus  outside) 
— total  long-term  expenditures  — and  be  considered  a 
major  systems  implementation  endeavor 


Processing 

The  need  for  providing  quality  management  reports  will 
be  determined  by  the  sponsoring  agency/department 
personnel  in  conjunction  with  the  IRMC  staff.  If 
agreement  cannot  be  reached  between  agency/department 
personnel  and  IRMC  stafT,  the  Chair  of  the  IRMC  will 
select  the  appropriate  reviewing  authority  for  a decision. 

Must  provide  quality  management  reports. 
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VENDOR'S 

APPROACH 

AND/OR 

OTHER 

MATERIAL 


NORTH  CAROLINA  STATE  GOVERNMENT 
QUALITY  MANAGEMENT  REPORTING 

RECEIPT  AND  REVIEW  OF  QM  REPORT 


* REQUIRED  ONLY  IF  NOT  PROVIDING  PERIODIC  PROJECT  PROGRESS  (STATUS)  REPORTS  FOR  THE  PROJECT  TO  THE  IRMC. 

IF  THE  AGENCY/DEPARTMENT  IS  GIVING  PERIODIC  PROJECT  PROGRESS  (STATUS)REPORTS  FOR  T HE  PROJECT  TO  THE  IRMC 
THE  GANTT  CHART  WILL  BE  SUBMITTED  THROUGH  THOSE  PROCEDURES. 


STATE  OF  NORTH  CAROLINA 
INFORMATION  RESOURCE  MANAGEMENT  COMMISSION 

IRMC  STAFF  QUALITY  MANAGEMENT  REVIEW  SHEET 


AGENCY  NAME:  

PROJECT  NAME:  

PROJECT  SPONSOR: 


PROJECT  IDENTIFICATION: 

PERIOD  COVERED: 

DATE  SUBMITTED: 

DATE  RECEIVED 

(IRMC  OFFICE):  


iIRMCSTAFF  CLASSIFICATION: 


□ 

□ 

□ 

□ 


EXEMPLARY  - Project  appears  to  be  in  excellent  shape. 

ROUTINE  - No  significant  issues/problems  identified  (see  comments  below). 

NEEDS  ATTENTION  - Major  actual  or  potential  issues/problcms  that  may  impact  adversely  the 
progress,  costs  and/or  results  (sec  comments  below). 

NOT  CLASSIFIED  AT  THIS  TIME  (Sec  comments  below). 


''  " ' 


IRMC  STAFF  COMMENTS:  „ 


-■  Jf,  mm  ' 

Mb KERRAL  INFORMATION: 


Referred  to  the  organization(s)  listed  below  for  further  detailed  review,  analysis  and  evaluation. 


IRMCFORM 


STATE  OF  NORTH  CAROLINA 
INFORMATION  RESOURCE  MANAGEMENT  COMMISSION 


Quality  Management  Report  Outline 

I.  Introduction: 

• State  agency  name,  project  name,  project  sponsor,  reviewer  name,  review  date,  scope  of  revieiv. 

• List  persons  who  participated  in  the  revieiv  and  indicate  each 's  role  in  the  project. 

II.  Project  Objectives  and  Background: 

• Provide  a brief  summary  of  the  overall  project's  major  objectives.  Include  both  business/program  and 
technical  objectives.  This  section  should  not  exceed  a paragraph. 

• Provide  a brief  summary  of  the  overall  project's  background  including  age  of  the  system  being 
replaced,  any  legislative  requirements,  and  prior  phases  of  the  systems  development  effort. 

III.  Busincss/Program  Proposal  Overview: 

Provide  a brief  description  of  the  project's  progress  toward  meeting  its  technical  and/or 
business/program  objectives  and  how  the  project  will  satisfy  the  envisioned  benefits.  This  section 
should  not  exceed  a paragraph. 

IV.  Technical  Overview: 

Provide  a brief  description  of  the  technical  architecture  being  employed.  This  section  should  not 
exceed  a paragraph.  Attach  an  one  pane  technical  schematic. 

V.  Major  Areas  of  Risk  o c Exposure  and  Other  Major  Findings: 

For  major  area  of  risk  or  exposure,  list  the  technical,  functional,  fiscal,  operational,  political  and/or 
other  areas  that  may  adversely  impact  the  successful  implementation  of  this  project  on-time,  within 
budget  and  with  all  expected  technical  and/or  business/program  benefits  being  delivered.  Each  risk 
area  should  include:  1)  Risk  description,  2)  Potential  impact  on  the  project,  and  3)  Management 
approaches  to  minimize  or  eliminate  the  risk.  Attach  the  Revieiver's  Findings. 

VI.  Outstanding  Points  from  Last  Quality  Management  Review: 

List  the  outstanding  points  from  the  last  quality  management  revieiv  and  how  each  was  or  will  be 
resolved. 

VIL  Project  Status: 

(This  section  is  required  only  if  the  agency/department  is  not  submitting  periodic  project  progress 
(status)  reports  for  the  project  to  the  IRMC.)  Provide  a brief  summary  of  the  overall  project's  progress 
in  terms  of:  1)  Total  actual  person  work  efforts  vs.  total  budgeted  person  work  efforts;  2)  Actual 
milestone  completion  dates  vs.  planned  milestone  completion  dates;  3)  Major  deliverables  completed 
vs.  planned  deliverables.  The  GANTT  chart  must  follow  the  format  prescribed  for  it  under  the  periodic 
project  progress  (status)  reporting  procedures. 


vm. 


Next  Quality  Management  Review: 

Note  anticipated  date  for  next  Oua  lit}'  Management  Revieiv. 
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Training  Matrix 


' 

Information  Technology  Training  Matrix 


BASIC  OFFICE  AUTOMATION  STANDARDS  TRAINING 
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Windows  - 3.1  (Beginning) 


E -mail  software  package 


Word  Processing  software  package 


Navigating  the  LAN/Internet 


[Spreadsheet  software  package 

OFFICE  AUTOMATION  SERIES 


Word  Processing  - Intermediate,  Advanced 


Spreadsheet  - Intermediate,  Advanced 


Graphics  Series 

DATA  BASE 


User  Specific  Database  Package 


|Smart  Stream  - Reporting  Function  | 

TECHNICAL  - COMPUTER  APPLICATIONS  TRAINING 


Basic  Help  Desk  Tmg  - Beginning,  Intermediate 


PC  T roubleshooting 


3270  Communications 


TCPIP 


Mainframe  Access/Communications 


Novell  Network  Engineer  - Series  ( 3 courses) 


Certified  Novell  Network  Engineer  (2  addt'l  courses) 


Programming  Language 


LAN  Troubleshooting 


Analysis  Trng  - Beginning,  Intermediate,  Advanced 


Systems  Integration 


Software  New  Release  Training 


Annual  Certification  Update  Training 


SDLC  Training 


Appendix  F 


Per  Seat  Estimate  for  LAN  Installation 


Per  Seat  Estimate  for  LAN  Installation 


In  order  to  estimate  the  cost  per  seat  on  an  average  network  in  this  Department  I 
complied  the  following  information: 

All  networks  must  include  a minimum  of  the  following  items  assuming  the  average 
network  size  of  32  users  per  LAN.  This  was  calculated  by  taking  the  number  of  workstations 
versus  the  number  of  LANs  referenced  on  page  22  of  the  12/8/95  draft  under  LAN 
Administration.  This  does  not  mean  that  this  should  be  the  number  of  users  a LAN 
Administrator  can  maintain.. 

■ A LAN  Administrator  (Computing  Consultant  III);  One  LAN  Administrator  per  LAN  of 
average  size.  With  an  annual  cost  of  approximately  $44,644.00  arrived  at  by: 


DEHNR  Personnel  supplied  a list  of  all  18  Computing  Consultant  HI 
positions  and  their  salaries  from  which  an  average  was  calculated.  The 
average  ended  up  being  $34,106.00. 

DEHNR  Budget  supplied  a break  down  of  the  benefits  associated  to  a 
position. 


Employer  contribution  to  retirement  1 0. 83% 

Employer  contribution  to  social  security  7.65% 

Employer  contribution  to  hospitalization  $1,735.00 


I estimated  an  annual  training  budget  of  $2,500.00  for  each  position. 


Position 

Retirement  10.63% 
Social  Security  7.65% 
Hospitalization 
Training 


$ 34,106.00 
$ 3,694.00 
$ 2,609.00 
$ 1,735.00 
$ 2,500.00 


Total 


$ 44,644.00 


■ The  LAN  hardware: 

■ File  Server 

Disk  Drive 
Network  Card 
UPS 

Tape  Drive 
Tapes 


$ 5,000.00 

$ 1,100.00 

$ 90.00  (Ethernet) 

$ 850.00 

$ 1,350.00 

$ 1,000.00  (20  Tape  Std.  Rotation) 


Total 


$ 9,390.00 


Based  on  ALR  from 
State  Contract 

Novell  Network  OS  $3,1 88.00 

82.36  Each  seat  = 17.28  per  year  Maintenance 
Workstation  Each  $ 2,000.00  (Including  Network  Card) 

Average  between  minimum  state  standards  and  Pentium. 

(2)  16  Port  Hubs  $ 1,808.00 

State  Convenience  Contract 


Shareable  Printer 

Network  Card 
Memory 
Envelope  Feeder 
Duplex 

Total 

State  HP  Contract  - Model  HP  4si. 

Wiring  Each  Location  $ 152.00 

A Recent  Installation  of  37  locations  cost  $ 5,635.00. 


$ 2,500.00 

$ 247.00  (Ethernet) 
$ 350.00 
$ 265.00 
$ 372.00 
$ 3,734.00 


Minimum  set  of  software 


Word  processing  $ 4,455.00 

State  Contract  100.80  Per  Seat  = 38.44  Per  Year  Maintenance 


Annual  training 

$ 2,240.00  ($70.00  * 32  Users  - One  day) 

■ Spreadsheet 

$ 5,616.00 

State  contract  144.00  Per  Seat  = 63.00  2 Year  Maintenance 

Annual  training 

$ 2,240.00  ($70.00  * 32  Users  - One  day) 

■ Database 

$ 2,500.00  (Est.  no  vendor  response) 

Annual  training 

$ 2,240.00  ($70.00  * 32  Users  - One  day) 

■ E-Mail 

$ 1,152.00 

State  Contract  30.00  Per  Seat  = 12.00  2 Year  Maintenance 

Annual  training 

$ 2,240.00  ($70.00  * 32  Users  - One  day) 

Total 

$22,683.00 

Summary: 

A LAN  Administrator  (Computing  Consultant  III)  $ 44,644.00(1) 

File  server 

$ 9,390.00(2) 

Novell  Network  OS 

$ 3,188.00(2) 

Workstation  Each 

$ 2,000.00(2) 

(2)  16  Port  Hubs 

$ 1,808.00(2) 

Shareable  Printer 

$ 3,734.00(2) 

Wiring  Each  Location 

(Avg)  $ 152.00 

Minimum  set  of  software 

$ 22,683.00  (io) 

Total  (Excluding  wiring  - already  averaged) 

Average  Per  Seat  Is  (including  wiring) 


$ 87,447.00 

$ 2,884.00 


(i)  Re-occurring  cost  each  year.  On  Software  the  training  portion  should  be 
budgeted  each  year. 

These  Items  should  be  budgeted  for,  on  a minimum  of,  every  two  years  to  maintain 
current  technology. 


(2) 


Appendix  g 


IRMT  Questionnaire  and  Customer  Survey 


IRMT  Questionnaire  and  Customer  Survey 

( 1 ) What  is  your  vision  for  IT  in  this  Department  for  the  next  five  years? 

(2)  What  are  your  current  problems  in  implementing  that  vision? 

(3)  If  you  could  change  things  about  our  IM  system,  what  would  it  be  and  why? 

(4)  How  will  your  Division  change  over  the  next  five  years? 

(5)  What  hardware/software/human  resources  do  you  currently  have?  (Broad  overview,  i.e. 
how  many  networks,  what  kind  of  human  resources  and  how  do  they  communicate?) 

(6)  What  electronic  information  do  you  have/maintain? 

(7)  Do  you  have  a disaster  recovery  plan  in  place? 

(8)  What  basic  IM  functions  do  you  see  as  essential? 

(9)  Do  you  currently  own  or  need  a GIS? 

( 1 0)  Are  you  willing  and  able  to  provide  through  training  for  all  employees  in  your  Division? 

(11)  What  can  you  tell  us  about  the  services  your  intemal/extemal  customers  need  from  you? 
Who  are  your  customers  specifically? 

( 1 2)  What  is  your  viewpoint  on  sharing  IT  with  other  Divisions? 

(13)  Do  you  currently  share  IM  resources  with  other  agencies? 

(14)  Does  your  Division  have  a proper  LAN  administrator  in  place,  and  can  you  afford  one? 

( 1 5)  What  are  your  feelings  about  fees  being  charged  by  DCS? 

( 1 6)  What  information  capabilities  do  you  think  should  be  in  the  Divisions,  and  within  the 
DCS? 

( 1 7)  What  is  your  perception  of  the  role  of  DCS? 

( 1 8)  What  support  level  would  you  like  from  the  Department? 

(19)  Is  there  anything  else  you  would  like  to  share  with  the  IRMT? 


. 


■ 


' 
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Appendix  H 


Phased  Funding  Strategy  Details 


IRMC  PROPOSAL 
PHASE  I 

SALARY 

F.T.E.  SALARY  SALARY  RESERVE 


POSITION 

NEEDED 

PC. 

NEEDED  AVAILABLE 

NEEDED 

CIO 

1.00 

New 

84 

$75,000.00 

$0.00 

$75,000.00 

Policy  Data  Admin. 

0.50 

80 

$21,952.00 

$20,493.00 

$1,459.00 

Policy/Plan  Gen. 

0.50 

80 

$21,952.00 

$20,493.00 

$1,459.00 

Admin.  Assistant 

0.50 

61 

$9,726.00 

$11,066.00 

Clerk  Typist  V 

0.50 

New 

57 

$8,311.00 

$0.00 

$8,311.00 

ITS  Director 

1.00 

82 

$48,045.00 

$67,252.00 

Admin.  Assistant 

0.50 

61 

$9,726.00 

$11,066.00 

Clerk  Typist  III 

0.50 

New 

57 

$8,311.00 

$0.00 

$8,311.00 

Senior  DBA 

1.00 

80 

$43,904.00 

$52,047.00 

Staff  DBA 

1.00 

78 

$40,073.00 

$34,081.00 

$5,992.00 

LAN  Administrator 

1.00 

76 

$36,563.00 

$32,896.00 

$3,667.00 

Senior  WAN/tel. 

1.00 

78 

$40,073.00 

$37,146.00 

$2,927.00 

Wan/telephony 

1.00 

74 

$33,413.00 

$33,576.00 

Systems  Integrator 

1.00 

80 

$43,904.00 

$55,594.00 

Lead  LAN  Admin. 

1.00 

80 

$43,904.00 

$50,482.00 

Trouble  Shooter/co. 

1.00 

78 

$40,073.00 

$39,324.00 

$749.00 

Arch/LAN  Admin. 

2.00 

76 

$36,563.00 

$41,996.00 

76 

$36,563.00 

$59,400.00 

Reg.  LAN  Admin. 

7.00 

76 

$36,563.00 

$38,189.00 

76 

$36,563.00 

$35,017.00 

$1,546.00 

76 

$36,563.00 

$31,720.00 

$4,843.00 

76 

$36,563.00 

$32,896.00 

$3,667.00 

76 

$36,563.00 

$32,164.00 

$4,399.00 

76 

$36,563.00 

$33,554.00 

$3,009.00 

76 

$36,563.00 

$33,554.00 

$3,009.00 

Contract  Admin. 

1.00 

74 

$33,413.00 

$35,093.00 

App.  Develop.  Mgr. 

1.00 

81 

$45,961.00 

$67,491.00 

Project.  Mgmt. 

2.00 

80 

$43,904.00 

$47,023.00 

80 

$43,904.00 

$32,354.00 

$11,550.00 

Systems  Analyst 

1.00 

78 

$40,073.00 

$52,832.00 

Systems  Analyst 

1.00 

New 

76 

$36,563.00 

$0.00 

$36,563.00 

Prog.  Analyst 

3.00 

74 

$33,413.00 

$27,520.00 

$5,893.00 

New 

74 

$33,413.00 

$0.00 

$33,413.00 

New 

74 

$33,413.00 

$0.00 

$33,413.00 

i on 

78 

$40073  00 

ts7  874  no 

Subtotal 

Needed  S.S. 
Needed  Retirement 

32.00 

$1,238,1 27.00 

$1,124,193.00 

$249,180.00 

$19,062.00 

$26,986.00 

$1041600 

TOTAL 

34.00 

$1,238,127.00 

$1,124,193.00 

$305,644.00 

IRMC  PROPOSAL 
PHASE  II 


POSITION 

F.T.E. 

NEEDED 

# 

P.G. 

SALARY 

NEEDED 

SALARY 

AVAILABLE 

SALARY 

RESERVE 

NEEDED 

Policy/Plan  Gen. 

1.00 

New 

80 

$43,904 

$0 

$43,904 

Quality  Assurance 

1.00 

New 

80 

$43,904 

$0 

$43,904 

Senior  DBA 

1.00 

New 

80 

$43,904 

$0 

$43,904 

Staff  DBA 

1.00 

New 

78 

$40,073 

$0 

$40,073 

Systems  Integrator 

1.00 

New 

80 

$43,904 

$0 

$43,904 

Trouble  Shooter/co. 

1.00 

New 

78 

$40,073 

$0 

$40,073 

Technology  Assess. 

1.00 

New 

78 

$40,073 

$0 

$40,073 

Contract  Admin. 

2.00 

New 

72 

$30,623 

$0 

$30,623 

New 

72 

$30,623 

$0 

$30,623 

Help  Desk  Mgr. 

1.00 

New 

78 

$40,073 

$0 

$40,073 

Help  Desk  Staff 

6.00 

New 

67 

$24,799 

$0 

$24,799 

New 

67 

$24,799 

$0 

$24,799 

New 

67 

$24,799 

$0 

$24,799 

New 

67 

$24,799 

$0 

$24,799 

New 

67 

$24,799 

$0 

$24,799 

New 

67 

$24,799 

$0 

$24,799 

2.00 

New 

67 

$24,799 

$0 

$24,799 

New 

67 

$24,799 

$0 

$24,799 

Tmg.  Coord. 

2.00 

New 

74 

$33,413 

$0 

$33,413 

New 

70 

$28,168 

$0 

$28,168 

Project  Mgr. 

3.00 

New 

80 

$43,904 

$0 

$43,904 

New 

80 

$43,904 

$0 

$43,904 

New 

80 

$43,904 

$0 

$43,904 

Systems  Analyst 

1.00 

New 

78 

$40,073 

$0 

$40,073 

Tech.  Writer 

1.00 

New 

68 

$25,841 

$0 

$25,841 

Clerical 

1.00 

New 

59 

$17,946 

$0 

$17,946 

Sec./Disaster  Rec. 

2.00 

New 

70 

$28,168 

$0 

$28,168 

New 

Zfl 

$78  168 

$Q_ 

$28.168 

Subtotal 

28.00 

$929,035.00 

$0.00 

$929,035.00 

Needed  S.S. 

Needed  Retirement 
Needed  Hnsn 

$71,071.00 
$100,614.00 
$48  608  00 

TOTAL 

28.00 

$929,035.00 

$0.00 

$1,149,328.00 

IR1MC  PROPOSAL 
PHASE  III 


SALARY 

F.T.E. 

SALARY 

SALARY 

RESERVE 

POSITION 

NEEDED 

U 

P.G. 

NEEDED 

AVAILABLE 

NEEDED 

Policy  Data  Admin. 

1.00 

New 

80 

$21,952.00 

$0.00 

$21,952.00 

Quality  Assurance 

1.00 

New 

80 

$43,904.00 

$0.00 

$43,904.00 

Staff  DBA 

1.00 

New 

78 

$40,073.00 

$0.00 

$40,073.00 

Data  Entry 

1.00 

New 

59 

$17,946.00 

$0.00 

$17,946.00 

Systems  Analyst 

2.00 

New 

76 

$36,563.00 

$0.00 

$36,563.00 

New 

76 

$36,563.00 

$0.00 

$36,563.00 

Prog.  Analyst 

8.00 

New 

74 

$33,413.00 

$0.00 

$33,413.00 

New 

74 

$33,413.00 

$0.00 

$33,413.00 

New 

74 

$33,413.00 

$0.00 

$33,413.00 

New 

74 

$33,413.00 

$0.00 

$33,413.00 

New 

74 

$33,413.00 

$0.00 

$33,413.00 

New 

74 

$33,413.00 

$0.00 

$33,413.00 

New 

74 

$33,413.00 

$0.00 

$33,413.00 

New 

74 

$33,413.00 

$0.00 

$33,413.00 

Tech.  Writer 

i on 

New 

68 

$25,841  Oft 

$0  Oft 

$25,841  Oft 

Subtotal 

15.00 

$490,146.00 

$0.00 

$490,146.00 

S.S. 

$37,496.00 

Retirement 

$53,083.00 

-Hosnitalbatinn 

$26,040  Oft 

Total 

1.00 

$490,146.00 

S0.00 

$606,765.00 

